One of the objectives of the IMS is to allow a user to access various services whatever his type of IP connectivity.
IMS networks, initially designed for mobile networks, tend to be developed with the highest priority on fixed access networks notably of the ADSL (Asymmetric Digital Subscriber Line) type, or FTTH (Fiber-to-the-home), or cable networks.
IMS architectures for fixed networks have, in particular, been deployed for the marketing of solutions known as “Multiplay”, allowing a user to access various services of the IMS network, and notably for Internet access, voice over IP (VoIP) and television over internet (IPTV) services via a domestic gateway.
In order to diversify their offer, the telecommunications operators now provide terminals complementary to the landline telephone, these complementary terminals being equipped with voice-over-IP (VoIP) software using at least the same public identifier IMPU as that of the domestic gateway and a private identifier IMPI which may or may not be the same as that of the domestic gateway.
It is recalled in this regard that, in order to register in an IMS network core, a terminal sends to this S-CSCF server (Serving Call State Control Function) responsible for the management of the registrations, a registration request notably comprising the two aforementioned identifiers.
The IMPI (IP Multimedia Private Identity) is an identifier allowing a terminal to be identified, this identifier also being used for the authentication of this terminal to the IMS network core, this authentication also requiring another parameter known to those skilled in the art under the name “SIP Password”.
The IMPU (IP Multimedia Public Identity) is the public identifier associated with the terminal, for example a telephone number.
It will be noted that these aforementioned identifiers IMPI, IMPU and the aforementioned parameter SIP Password can be stored in a configuration file downloaded by the domestic gateway when it boots up.
In practice, in the prior art, after attaching itself to a domestic gateway, an SIP terminal obtains an IP address from a DHCP server integrated into this gateway, solicits a specialized server to download its VoIP configuration file comprising the aforementioned identifiers IMPI, IMPU, and SIP password then the domain name of the IMS network in order to request its registration in the IMS network core.
In a known manner, after obtaining an IP address from the network, for example via a DHCP server, the VoIP software stack of the domestic gateway initially registers in the core of the IMS network then subsequently re-registers with a period defined by a parameter EXPIRES typically of the order of one hour.
Each of these successive registrations consists in supplying to the IMS network core, aside from the information linked to the authentication, two pieces of information composed of:                a parameter AoR (Address of Record) corresponding to the public identity IMPU representative of the logical address at which said terminal can be contacted; and        a parameter AoC (Address for Contact) corresponding to the IP address and to the port number of this terminal representative of the physical address at which said terminal can be contacted.        
Since several terminals having the same public identity IMPU (domestic gateway, fixes or mobiles of voice-over-IP fixed or mobile terminals, etc.) can make a request to be registered in the S-CSCF server, the manufacturers of S-CSCF entities have set up means for monitoring the number of SIP registrations for the same identity IMPU.
This monitoring can notably consist in:                setting a maximum number of terminals that can register with the same public identity IMPU; and in        implementing a policy to be applied in the case where several SIP registration requests carrying the same public identity IMPU are received.        
A known policy notably consists in limiting the number of terminals that can register in the network core with the same public identity IMPU and in unregistering the terminal that had registered first, in order to allow a new terminal to register, according to a FIFO (First In First Out) mechanism.
The aforementioned complementary terminals can notably be mobile terminals connected to the domestic gateway by a wireless connection of the Wifi type.
Owing to their mobility, the management of the registration of these terminals in the IMS network poses a particular problem. Indeed, if a mobile terminal leaves the Wifi area and re-enters the latter, it will not be automatically unregistered when leaving the Wifi area but, when it re-enters, it will re-register in the network core with potentially a new contact address, and these successive registration attempts can lead to the rejection of the domestic gateway and that of other already registered terminals, by application of the policy of the FIFO type mentioned hereinabove.
In order to avoid this problem, one solution consists in verifying, with the specialized server mentioned hereinabove, whether the maximum number of terminals carrying the same public identity IMPU has already been registered within the IMS network, and in refusing the registration of the complementary terminal if this is already the case by not supplying it with its VoIP configuration parameters (IMPU, IMPI, password notably).
In order to obtain this information, the specialized server must interrogate the SLF (Service Location Function) in the case of an extensive IMS network in order to find out on which HSS the IMPU is hosted, then the HSS (Home Subscriber Service) in order to find out on which S-CSCF server the gateway and/or at least one SIP terminal carrying the public identity IMPU are registered, then once the identification of the S-CSCF has been obtained, the specialized server uses a method defined in the Internet Engineering Task Force (IETF) SIP specification RFC3261 which consists in sending to the S-CSCF an SIP REGISTER request having as parameters the public identity IMPU and a contact address =“*”. The response generated by the S-CSCF, 200 OK, supplies a list that can contain from 0 to n contact addresses and, for each one of them, the value of the remaining duration of registration.
This solution is not very satisfactory because it increases the complexity of the processing operations of the specialized server, generates complementary loading in the SLF, HSS and the S-CSCF, and requires physical data streams to be opened within the firewalls between the aforementioned servers which weakens the overall level of security. In addition, this method leads to unavailability of the VoIP service for the VoIP terminals, typically when a terminal is not able to unregister itself in the network core upon loss of IP connectivity (loss of WiFi), or when the terminal must be rebooted. In this case, since the configured maximum number of registrations is already reached, the VoIP configuration parameters are not supplied to the terminal for the maximum duration equal to the value of the field Expires globally configured within the S-CSCF. Similarly, this unavailability of service can be generated by the gateway itself, the currently known gateways not having the possibility of unregistering themselves following a reboot.